Initial setup: Most systems need setup. Don’t even discuss work before this gets completed. Make sure the new dev is where they need to be. Stressing out about getting work done while struggling to get your system working is a guarantee of starting out on the wrong foot for everyone.
The first two weeks after setup is completed are allotted for the new developer to learn the codebase he or she will be working with. Eliminate any major focus besides learning— the new hire’s only task is to become familiar with the code, systems, and processes that are in use. The investment of two weeks will be more than made up for in productivity as the new hire starts contributing with the familiarity and comfort provided by two weeks of learning.
Other developers can be under advisement during that two week period that the hire will probably have questions. If it’s better for the developers not to be disturbed, there can be a general understanding of some medium through which the new developer can ask questions without interrupting anyone, like a channel on Slack, or a company forum, or an email list. The other developers must watch this medium more closely during that period, and the hire can then feel free to ask as many questions as necessary via that channel, without worrying about who to ask and how often is too often to bother people. Likewise the existing developers only have to look at this medium and answer questions when they’re in between tasks and have a few spare moments. This will make the first couple weeks a bit more smooth for everyone.
Implement a “rotation” where one developer at a time is on standby, ready to answer the new hire’s questions at any given time (during work hours, of course). During this time that developer’s load can be reduced in the light of that additional task. Again, this two week period is an investment.
As the two weeks conclude the new hire can also be assigned certain basic tasks that allow him or her to actively contribute while they learn the code — for instance, a task of writing up basic documentation for every process they learn, so for instance if someone showed them how to deploy code to the staging environment, they could write this up and then make it available to future hires to make the learning process smoother the next time. Likewise, a new hire in the ramp-up period could add comments to the code wherever gaps in comments exist, giving him or her an opportunity to become familiar with the code but also help everyone handle the code a little bit better. The new developer is at once learning and contributing, to everyone’s benefit.